Complex electronic, electromechanical and mechanical devices are generally tested using automated test systems. The tests may include validation tests, which run through various operations of a device under test (DUT) and record whether each operation was performed properly. The tests may also include environmental tests, which expose the DUT to various combinations of temperature, pressure, and humidity to record the results of operations as the environment changes. Other tests, such as production tests, may also be completed. Generally, both the DUT and the systems providing the environmental and other constraints on the DUT are controlled electronically. In the last decade or so, computerized programs which are capable of controlling a variety of automated tests, referred to in the art as “test executive” programs, have been developed.
Test executive programs in the prior art include internal test executive programs developed by Agilent Technologies and TESTSTAND software developed by National Instruments Corporation, which is described as a ready-to-run test executive for organizing, controlling, and executing automated prototype, validation, or production test systems. The prior art Agilent Technologies programs did not use a graphical user interface (GUI), therefore limiting the ability of the program to display large amounts of data in a simple fashion. The TESTSTAND software, while using a GUI, requires the user to scroll through multiple windows to determine the overall progress of a test and therefore does not lend itself to ease of test reconfiguration.
Tests usually are defined by a set of rules or specifications to which the DUT is compared. The rules or specifications generally comprise various inputs defined by electrical and mechanical parameters applied to the DUT, such as voltage, current, specified manipulations of controls and device parts, as well as environmental parameters under which the test is conducted, such as temperature, humidity, pressure, and the time period over which a parameter is applied. Each test includes many combinations of the parameters applied to each element of the DUT, and often will be repeated many times. Each combination of parameters will define a measurement that results in one or more datapoints, which are recorded and compared to numerical or Boolean limits defining the specifications. Thus, as devices become more complex, electronic test programs have become very long and complex, often requiring several days, or even a week or more to run a complete test.
It is a problem that users sometimes want to only run certain procedures or tests on a DUT. For example, a user may want to verify results of some tests after the tests have been completed. Specifically, a user may view the results of test performed on a DUT and learn that some tests have failed or marginally failed. The user may then desire to perform the tests a second time to verify the results or find the reason that the test failed. In the prior art systems, the only way to perform a specific test or procedure a second time was to perform the entire test a second time. This is very time consuming and may not isolate the cause of the failure.